1. Field of the Invention
This invention relates to network computing, and more particularly to serialization mechanisms for data transmitted between clients and servers in RMI-IIOP implementations.
2. Description of the Related Art
RMI
RMI (Remote Method Invocation) is a way that a programmer, using the Java programming language and development environment, can write object-oriented programs in which objects on different computers can interact in a distributed network. RMI is the Java version of what is generally known as a remote procedure call (RPC), but with the ability to pass one or more objects along with the request. The object can include information that will change the service that is performed in the remote computer. The object parameter-passing mechanism may be referred to as object serialization. An RMI request is a request to invoke the method of a remote object. The request has the same syntax as a request to invoke an object method in the same (local) computer. In general, RMI is designed to preserve the object model and its advantages across a network.
RMI may be implemented as three layers:                A stub (proxy) program in the client side of the client/server relationship, and a corresponding skeleton at the server end. The stub appears to the calling program to be the program being called for a service.        A Remote Reference Layer that can behave differently depending on the parameters passed by the calling program. For example, this layer can determine whether the request is to call a single remote service or multiple remote programs as in a multicast.        A Transport Connection Layer, which sets up and manages the request.        
A single request travels down through the layers on one computer and up through the layers at the other end.
CORBA, IIOP, and ORB
IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs written in different programming languages to communicate over the Internet. IIOP is a critical part of an industry standard, the Common Object Request Broker Architecture (CORBA). CORBA is an architecture and specification for creating, distributing, and managing distributed program objects in a network. CORBA allows programs at different locations and developed by different vendors to communicate in a network through a broker that mediates remote requests.
An essential concept in CORBA is the Object Request Broker (ORB). An Object Request Broker (ORB) acts as a “broker” between a client request for a service from a distributed object or component and the completion of that request. ORB support in a network of clients and servers on different computers means that a client program (which may itself be an object) can request services from a server program or object without having to understand where the server is in a distributed network or what the interface to the server program looks like. Using ORBs, components can find out about each other and exchange interface information as they are running. To make requests or return replies between the ORBs, programs may use the General Inter-ORB Protocol (GIOP) and, for TCP/IP, Internet Inter-ORB Protocol (IIOP). IIOP maps GIOP requests and replies to the Internet's Transmission Control Protocol (TCP) layer in each computer
CORBA and IIOP assume the client/server model of computing in which a client program makes requests and a server program waits to receive requests from clients. When writing a program, an interface is used called the General Inter-ORB Protocol (GIOP). The GIOP is implemented in specialized mappings for one or more network transport layers. An important specialized mapping of GIOP is IIOP, which passes requests or receives replies through the Internet's transport layer using the Transmission Control Protocol (TCP). Other possible transport layers may include, but are not limited to, IBM's Systems Network Architecture (SNA) and Novell's IPX.
RMI-IIOP
When a client communicates with a server using the IIOP protocol to access RMI objects on the server, the communication process may be referred to as RMI-IIOP because calls from the client target RMI objects on the server, and access to the RMI objects on the server is enabled through an IIOP mechanism.
Java Interface Definition Language (IDL) adds CORBA capability to the Java platform, providing standards-based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP. Java IDL technology may be used by CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA Interface Definition Language (IDL). This is “business as usual” CORBA programming, supporting Java technology in a similar way as other languages such as C++ or COBOL.
Interoperable Object Reference (IOR)
Remote references are used by clients to invoke remote operations on servers. In CORBA, a remote reference to an object on a server may be referred to as an Interoperable Object Reference (IOR). An IOR is a network-addressable (remote) reference as defined by CORBA. In RMI-IIOP, an IOR may be encapsulated in a Java object referred to as an RMI-IIOP stub.
Common Data Representation (CDR)
Client and server programs may deal with data that must be marshaled into a standard form before it can be passed in messages. The standard form (or external data representation) supports both data structures and primitive data items. CORBA encodes messages in a binary format called CDR (Common Data Representation). CORBA CDR is designed for use by a variety of programming languages. CDR is a transfer syntax that maps Interface Definition Language (IDL) types from their native host format into a common binary representation. CDR-encoded messages may be used to transmit CORBA requests and server responses across a network. All IDL data types are marshaled using the CDR syntax into a stream that contains the marshaled data.
FIG. 1 is a block diagram illustrating a conventional RMI-IIOP implementation. RMI-IIOP implementations generally follow CORBA guidelines, specifications, and requirements. There are essentially two parts to RMI-IIOP: protocol and encoding. Following the CORBA guidelines, RMI-IIOP conventionally uses General Inter-ORB Protocol (GIOP), according to the CORBA specification, for the protocol, and CDR (Common Data Representation) for encoding.
In FIG. 1, a CORBA client 110 is shown using RMI-IIOP through client-side ORB 112 and server-side ORB 102 on server 100 to access object(s) 106 on the server 100. Server 100 may be an application server instance on a server system; a server system may include one or more instances of an application server. Note that client 110 may itself be a server or an application on another or the same server. Objects 106 may reside in one or more containers 104 on server 100. A container 104 is an entity that provides life cycle management, security, deployment, and runtime services to objects 106. An object 106 may be defined as an application-level software unit supported by a container 104. J2EE objects may include development and deployment units in the EJB tier and Web tier. Objects 106 may include one or more of, but are not limited to, EJBs (Enterprise JavaBeans), JSPs (JavaServer Pages) and Servlets. Containers 104 provide support for the objects 106, providing for reliable and standardized object-specific services. Various types of containers (e.g., EJB, Web, JSP (JavaServer Pages), Servlet, applet, and application client) may provide object-specific services.
Client 110 may desire or need to invoke an object 106 on server 100. To invoke an object, client 110 needs information about the object 106, such as where the object 106 is located. To obtain this information, client 110 may access a naming registry, for example a CORBA naming service, to obtain an object reference (IOR 120) for the object 106. An IOR 120 may include information for accessing the associated object 106. For example, an IOR 120 may include one or more of, but is not limited to, the host name, port name, and Quality of Service (QoS) information.
After obtaining an IOR 120, the client 110 may make an invocation on the target object 106 on the server 100. When client 110 makes an invocation of an object 106 on the server 100, the client-side ORB 112 constructs a message 132 formatted in accordance with GIOP that may then be sent to the server 100 via RMI-IIOP. There are different types of messages 132 supported the GIOP protocol. The type of message 132 used is appropriate to the nature of the particular call being made. For invocation of an object 106, a request message may be used. Messages 132 may be constructed by the client-side ORB 112. To construct a message 132, data 114 appropriate to the message 132 may be marshaled into one or more message buffers. For example, a target object 106 to be invoked which is a method “FOO( )” may require one or more parameters, which may be of integer, Boolean, string, real, or any other data type. The parameters from the client side are marshaled into the message buffers so that they can be sent “over the wire” to the server 100 in a message 132. Conventionally, RMI-IIOP implementations use CDR, a data encoding format from the CORBA specification, as the encoding for data marshaled into messages 132. The messages 132 may then be sent “over the wire” to the server 100, where the server-side ORB 102 may unmarshal the CDR-encoded data from the messages into a data format used by the object 106 being invoked on server 100, which may or may not be the same data format used on client 110. Note that the invoked object 106 on server 100 may generate one or more response messages to client 110. In sending response messages, server-side ORB 102 may marshal data formatted in accordance with a data format used by the invoked object 106 into CDR. Client-side ORB 112 may unmarshal the CDR-encoded data from received response messages into a data format used on client 110.
Java Serialization
The Java platform allows the creation of reusable objects in memory. However, the objects exist only as long as the Java virtual machine remains running. Object serialization is the process of saving an object's state to a sequence of bytes, as well as the process of rebuilding those bytes into an object. The Java Serialization API, which is part of the Java Developer's Kit (JDK), provides a standard mechanism for the serialization of Java objects. Serialization involves saving the current state of an object to a stream, and restoring an equivalent object from that stream. The stream functions as a “container” for the object. The stream's contents include a partial representation of the object's internal structure, including variable types, names, and values. The stream, or container, may be transient (RAM-based) or persistent (disk-based). A transient stream, or container, may be used to prepare an object for transmission from one computer to another. A persistent stream, or container, such as a file on disk, allows storage of the object after the current session is finished. In both cases, the information stored in the stream may later be used to construct an equivalent object containing the same data as the original.